Pervasive computing is, as described in [2], Brent A. Miller, Robert A. Pascoe, Salutation Service Discovery in Pervasive Computing Environments, IBM® Pervasive Computing White Paper, February 2000, the next evolution of network computing, which evolved from client server computing. The appearance of new information appliances and types of connectivity is spurring a new form of networking. Users of mobile computing devices such as notebooks, mobile phones or palm tops frequently require to transfer data to other mobile or to fixed devices for example for storing, displaying, printing or transmitting said data. For the replacement of cables previously used to connect the corresponding computing devices, networking systems, such as Bluetooth, have been created which allow the set up of unmanaged, dynamic networks also described as ad-hoc networks or pervasive networks.
Computing devices using for example the Bluetooth technology may initiate the set up of an ad-hoc network, at this stage a so called point to point piconet, or may access an already set up ad-hoc network which by this may be extended from a point to point piconet to a point to multipoint piconet or to a scatternet. An important aspect of modern ad-hoc networks is that various devices which offer different services may access the network or may be accessed through the network. Mobile phones or digital cameras may wirelessly be connected to notebooks which themselves establish links to printers. Devices may instantaneously enter or leave ad-hoc networks. A remote control for example which is carried through a building may sequentially connect to various different devices which then can be set to a desired operating condition by the user.
In order to achieve an optimal configuration of the ad-hoc network means and technologies must be provided to the devices to declare and communicate their requirements and services.
Technologies have been developed, for example by The Salutation Consortium (see http://www.salutation.org), which are intended to provide devices, applications and services, which meet in a communication setting, the ability to find out about each other by means of electronic messages or salutations. Once the concerned devices have exchanged information about their capabilities, they may tailor their interactions accordingly. A salutation manager SLM may be incorporated in the Bluetooth protocol stack which is described below.
The Bluetooth protocol stack, which is shown in FIG. 1 and described in [4], Bluetooth Protocol Architecture, pages 4 and 5, comprises Bluetooth Core Protocols 10. These include Base band and Link Controller Protocols 20, Link Manager LM 30, Logical Link and Adaptation Protocol LL2CAP 40 which together with a radio part 50 and a host controller interface HCI 60 correspond to the Physical Layer, Data Link Layer, Network, Layer Transport Layer and Session Layer of the OSI reference model (see [1], page 7). Further shown in FIG. 1 are Telephony Control Protocols TCS and Cable Replacement Protocol RFCOMM 80 which supports Object Exchange Protocol OBEX 90, Wireless Application Protocol WAP 100 and a set of Telephony Control AT Commands 110 based on the well-known industry standard Hayes Smartmodem commands.
The Bluetooth Core protocols further comprise a service discovery protocol SDP 120 that enables the retrieval of information that can be used to configure the stack to support several end-user applications. In particular, the service discovery protocol SDP 120 can be used to locate services that are available in the vicinity of the user. Having located available services, a user may then select to use any of them. However before information can be retrieved from other devices corresponding connections have to be established.
To establish new connections, the procedures inquiry and paging are used. Referring to FIG. 2, a Bluetooth device may change from the STANDBY state 200 to a Page Scan (PAGE) 210 or Inquiry Scan (INQUIRY) 220 sub-state to scan for page or inquiry messages or to page 230 or inquiry 240 to initiate the process of establishing a new connection (see [3], page 98, state diagram of the Bluetooth link controller).
Referring to FIG. 5, in the paging and inquiry procedures, the device access code DAC and the inquiry access code IAC are used respectively. A unit in the page scan 210 or inquiry scan 220 sub state correlates against the respective access codes with a matching correlator.
The inquiry procedure enables a unit to discover which units are in range, and what the device addresses and clocks are. In the Bluetooth system, an inquiry procedure is used in applications where the destination's device address is unknown to the source. In the INQUIRY sub state 220, the discovering unit continuously transmits an inquiry message and collects the Bluetooth device addresses and clocks of all units that respond to the inquiry message. The discovering unit can then, if desired, change to the PAGE sub state 210 and set up a connection to any of the units which have replied to the inquiry message. When carrying out a successful page attempt, the unit will enter the CONNECTION state 250 as a master. The unit responding to the page message will enter the CONNECTION state 250 as a slave.
The inquiry message broadcasted may comprise a General Inquiry Access Code GIAC inquiring for any Bluetooth device or a Dedicated Inquiry Access Code DIAC which indicates the class of devices that should respond.
The intervals between scan activities are typically not more than 2-3 seconds.
In practise a user may activate a Bluetooth supported device such as a notebook and start a word processing application. For the printout of a document, the notebook requires the services of a printer. The notebook therefore emits a series of inquiry messages comprising a Dedicated Inquiry Access Code DIAC which specifies the required devices and eventually a printer replies with a Frequency Hop Synchronisation packet FHS which contains all the information required for establishing a connection (see [3], page 56).
To retrieve information from a remote device, a connection is established by means of the described access procedures. Then the services that are available from or via the connected remote device are located by means of the service discovery protocol SDP 120. The service discovery protocol defines the protocols and procedures that to be used by the service discovery application in the local device to locate services provided by server applications in the remote device as well as the attributes of those services. The server maintains a list of service records that describe the characteristics of services associated with the server. Each service record contains information about a single service. As seen in FIG. 4 a service record contains at least a Service Record Handle (attribute ID 0x000) and a Service Class ID List (attribute ID 0x0001). Other service attributes are optional (see [3], page 358, service attribute definitions).
FIG. 3 shows the Bluetooth protocols and supporting entities involved in the service discovery profile. A service discovery user application 310 in a local device 300 interfaces with a service discovery client SDPC 320 in order to send service inquiries to, and to receive service inquiry responses from, a service discovery server SDPS 330 of a remote device 340 which is connected to a database DB 350 comprising a list of service records. Service discovery entities SDP use the connection oriented transport service CO 360 of the logical link and adaptation entity L2CAP 40 which in turn uses baseband asynchronous connectionless links ACL 380 to ultimately carry SDP protocol data units SDP PDUs 390 shown in FIG. 4.
After the required service information has been collected, initiated by the paging process a further connection can be set up to the remote device 340. The application 360 sends its requirements through the host controller interface HCI 60 to the link manager LM 30 which in turn sets up a connection as required (see [1], pages 13-16).
As detailed above the process of accessing a remote device 340 by means of inquiry access codes and subsequently retrieving information from the remote device 340 comprises numerous steps which are performed in time intervals of considerable length. In an error free environment, following a inquiry message it may take up to ten seconds to receive all responses from remote devices 340. Setting up connections 250 and retrieving the information by means of the service discovery procedures is time consuming as well.
Using a Dedicated Inquiry Access Code DIAC instead of a General Inquiry Access Code GIAC which indicates the class of devices that should respond can save time.
However since the numbers of services and the devices which may participate in an ad-hoc network are expected to increase significantly, the time required for service discovery compared to the time left for actually using the discovered services becomes relatively high. Further, it is important to note that devices are entering and leaving an ad-hoc network within short time intervals and may nevertheless require the use of available service. Keeping the list of available services updated is therefore a continuously running process. In addition, communication traffic in such networks is often bursty so that time for administrative tasks such as service discovery may severely be limited during certain time periods since devices which are engaged in communications are performing service discovery procedures with low priority.
To facilitate access to service information, it has been proposed to establish a device in the network collecting all available service information which then can be retrieved by other devices. This however introduces a static element into a dynamic network which does not fit well into a dynamic network. It would be desirable to provide a method, a network device and a computer program product for improving the described service discovery procedures used in a pervasive network. It would also be desirable to transfer service information to a device of a pervasive or an ad-hoc network practically without absorbing capacity of the communication channels. It would be further desirable to avoid multiple downloading of identical service information from a device connected to the network. Still further, it would be desirable to specify an implementation of the invention in a system operating according to the Bluetooth standards.